IMS-based discovery and control of remote devices

ABSTRACT

The present invention faces the issues of remotely controlling multiple LAN-attachable devices (1a-1m) and provides for means and method of controlling the LAN-attachable devices from a CP-terminal (2) through an IMS network (51, 52). Basically, the invention provides for the allocation of unique identifiers to each LAN-attachable device (S-020), the exposure of these identifiers in an appropriate entity under control of a SIP network operator (S-045), fetching these identifiers from the CP-terminal (S-050), the submission of control commands from the CP-terminal through the IMS network towards a Remote Gateway (S-055), where the LAN-attachable devices are accessible through a home LAN network, and the submission of corresponding control command from the Remote Gateway towards the LAN-attachable devices (S-060).

This application is the U.S. national phase of International ApplicationNo. PCT/EP2008/064691 filed 29 Oct. 2008, which designated the U.S. andclaims the benefit of U.S. Provisional No. 61/015,298 filed 20 Dec.2007, the entire contents of each of which are hereby incorporated byreference.

TECHNICAL FIELD

The technology herein generally relates to the control of home devicesconnected to a Local Area Network, like personal video recorders, TV,washing machines, etc, from a so-called Control Point terminal havingdata connectivity to said Local Area Network.

BACKGROUND

At present, homes and offices have pluralities of so-called ConsumerElectronics (hereinafter CE) devices like Residential Gateways(hereinafter RGW), TV, Personal Video Recorders, Media Centres, etc,which are enabled for connecting to a Local Area Network (hereinafterLAN). Other non-CE devices like washing machines, refrigerators,surveillance devices, etc, may also be enhanced to be LAN-attachable. Aso-called home-LAN may thus include home CE devices and home non-CEdevices attachable to said home-LAN, and which are accessible andcontrollable from a Control Point (hereinafter CP), the latter havingdata connectivity to said home-LAN. These CE and non-CE attachabledevices are further referred to as LAN-attachable devices throughout thepresent specification.

In particular, a CP may be a cellular handset directly attached to thehome-LAN, namely a so-called LAN-home-attached CP, such as thoseterminals with WLAN connectivity, or remotely attached to the home-LANthrough a Public Data Network (hereinafter PDN), namely a so-calledLAN-remote-attached CP.

A conventional way of remotely attaching a LAN-remote-attached CP to thehome-LAN is by means of a Virtual Private Network (hereinafter VPN)established between a LAN-attachable device attached to the home-LAN,such as a RGW may be, and the LAN-remote-attached CP attached to a PDN.The VPN comprises a transparent end-to-end tunnel through the PDN,providing secure exchange of point-to-point frames between theLAN-attachable device and the LAN-remote-attached CP, said tunnel beingused to exchange frames carrying control data blocks.

In this respect, and before exchanging commands with a LAN-attachabledevice, a CP needs to discover its existence and to identify thatLAN-attachable device for addressing purposes. This task is usuallyperformed by means of some domain-specific protocol, like UPnP, SIP, andother domotic control protocols. For example, US-2006/0133392 disclosesthe interworking between a SIP compliant terminal in an external networkfor remotely handling home devices through a gateway that includes apresence server for registering devices in a home network, devices whichcommunicate with the gateway via a UPnP protocol. Also for example,US-2007/0143489 addresses the issue of interworking between a local areanetwork where first appliances are connected via a UPnP protocol and awide area network, such as an IMS network, where second appliances areconnected via an IMS protocol. Moreover, each particular LAN-attachabledevice usually supports one particular domain-specific protocol with aparticular identification procedure. Thus, any client application in aCP has to support a plurality of domain-specific protocols for aneffective control of a variety of LAN-attachable devices in thehome-LAN. Furthermore, especially where the CP is a LAN-remote-attachedCP, said CP may also require different attach procedures to the home-LANthrough the PDN depending on individual domain-specific protocols.

In summary, a LAN-remote-attached CP willing to remotely controlmultiple LAN-attachable devices conventionally needs the establishmentof a VPN tunnel to the home-LAN and, then, using multipledomain-specific protocols, the LAN-remote-attached CP needs a discoveryof the identifiers of those LAN-attachable devices. Moreover,establishing a transparent end-to-end VPN tunnel is a heavy task toperform by the tunnel ends, wherein encryption and/or authenticationsuites need to be negotiated and agreed, keys need to be exchanged, andprotocol stacks need to be set up. This may result into a lengthyprocess, not suitable for an application requiring high responsiveness,such as for switching-on the heating system. In addition, using anend-to-end VPN tunnel prevents the operator of the PDN from providingvalue-added services to the user like, for example, programming someoperations to be performed at certain periods, since the operator doesnot have access to the home-LAN and does not know how to identify eachLAN-attachable device.

SUMMARY

Certain example embodiments aim to at least minimize the above drawbacksand provides for means and method of controlling a number ofLAN-attachable devices from a CP registered in an IMS network, and notnecessarily being a so-called LAN-remote-attached CP.

Basically, certain example embodiments provide for the allocation ofunique identifiers to each LAN-attachable device, the exposure of theseidentifiers to an application running in the CP and, advantageously,also in an appropriate entity under PDN operator control.

In accordance with a first aspect, there is provided a new method ofcontrolling one or more devices attachable to a Local Area Network,hereinafter ‘LAN-attachable devices’, from a Control Point terminal,hereinafter ‘CP-terminal’, remotely attachable to said Local AreaNetwork, hereinafter ‘LAN’, through an IP Multimedia Subsystem,hereinafter ‘IMS’, network.

This method comprises the steps of: registering a first IMS device ofthe Residential Gateway with a first IMS network holding a subscriptionfor said first IMS device; discovering from the Residential Gatewaythrough the LAN a list of identifiers of LAN-attachable devices; foreach identifier of a LAN-attachable device, hereinafter “LAN-ADI”, theResidential Gateway: generating a universal unique identifier “UUID” andassociating said UUID with its corresponding LAN-ADI; sending at leastone UUID from the Residential Gateway towards a discovery server;registering a second IMS device of the CP-terminal with a second IMSnetwork holding a subscription for said second IMS device; the secondIMS device obtaining one or more UUID from the discovery server; thesecond IMS device submitting through said first and second IMS networksone or more IMS commands addressing the one or more UUID towards theResidential Gateway; and the Residential Gateway submitting through theLAN corresponding commands addressing each corresponding LAN-ADI to eachLAN-attachable device.

Generally speaking in this method, each UUID may be accompanied by arespective Session Initiation Protocol, hereinafter “SIP”, address foraddressing the corresponding LAN-attachable device through said firstand second IMS networks.

Advantageously in this method, the step of discovering from theResidential Gateway the list of identifiers of LAN-attachable devicesmay include a step of requesting to one or more domain-specific devicesof the Residential Gateway a discovery of the LAN-attachable devices inaccordance with corresponding one or more domain-specific protocols anda step of receiving the identifiers of LAN-attachable devices from theone or more domain-specific devices of the Residential Gateway.

Also advantageously in this method, the step of submitting correspondingcommands from the Residential Gateway includes a step of mapping the oneor more IMS commands into corresponding domain-specific protocolcommands understandable by the LAN-attachable devices.

In an embodiment, the discovery server is a Presence Server of the firstIMS network and the method may further include a step of publishing theat least one UUID from said Presence Server. This is an advantageousalternative not loading other entities of the IMS network.

In another embodiment, where entities of the IMS network under a directcontrol of the operator are wanted to be involved in this method, thestep of registering the first IMS device includes a step of assigning aServing Call Session Control Server, hereinafter “S-CSCF”, of the firstIMS network to the first IMS device as a result of this registration,and the step of sending the at least one UUID towards the discoveryserver may include a step of registering the at least one UUID from thefirst IMS device towards said S-CSCF.

In a first alternative under the latter embodiment, the discovery servermay be this S-CSCF of the first IMS network. In a second alternativeunder the latter embodiment, the method may further comprise a step ofsubmitting the at least one UUID registered in the S-CSCF towards aPresence Server of the first IMS network and a step of publishing the atleast one UUID from said Presence Server, and the discovery server maybe said Presence Server.

On the other hand, particularly in this method the first and second IMSnetworks may be a same IMS network.

In accordance with a second aspect, there is provided a new ResidentialGateway for accessing to a LAN, wherein one or more LAN-attachabledevices are attachable thereto, from an IMS network wherein aCP-terminal is connected thereto.

This Residential Gateway comprises: an IMS device having a subscriptionwith an IMS network and arranged for registering and communicating withsaid IMS network; one or more domain-specific devices for discovering alist of identifiers of LAN-attachable devices “LAN-ADI” through the LAN;a coordination agent arranged for generating a UUID per each LAN-ADI,and for associating said UUID with its corresponding LAN-ADI; thiscoordination agent being arranged for cooperating with the IMS devicefor sending at least one UUID towards a discovery server; the IMS devicebeing arranged for cooperating with the coordination agent for receivingfrom the IMS network one or more IMS commands addressing the one or moreUUID; and the coordination agent being arranged for cooperating with theone or more domain-specific devices for submitting through the LANcorresponding commands addressing each corresponding LAN-ADI to eachLAN-attachable device.

This Residential Gateway may, for the sake of improving modularity,further comprise one or more domain-specific protocol modules forhandling the one or more domain-specific devices to carry out thediscovery procedure of the LAN-attachable devices, to receive theidentifiers of LAN-attachable devices, and to submit the correspondingcommands for each LAN-attachable device.

Particularly advantageous where the LAN-attachable devices handledifferent domain-specific protocols, the one or more domain-specificdevices may operate in accordance with corresponding one or moredomain-specific protocols respectively handled by the LAN-attachabledevices.

Also for the sake of improving modularity, the Residential Gateway mayfurther comprise an IMS protocol module for handling the IMS device toregister in the IMS network, to send the at least one UUID towards thediscovery server and to receive from the IMS network the one or more IMScommands addressing the one or more UUID.

In particular, where Residential Gateway includes the above IMS protocolmodule and the above one or more domain-specific protocol modules, theResidential Gateway may advantageously comprise a controller forinterfacing the IMS protocol module and the one or more domain-specificprotocol modules, and for mapping the one or more IMS commandsaddressing the one or more UUID into the corresponding commandsaddressing each corresponding LAN-ADI.

On the other hand, in order to avoid continuous generations of UUDI andassociations with corresponding LAN-ADI, the Residential Gateway mayfurther comprise a storage arranged for storing each UUID associatedwith its corresponding LAN-ADI per each LAN-attachable device. Moreover,where different domain-specific protocols are required for handling theLAN-attachable devices, this storage may be arranged for storing anindication of the applicable domain-specific protocol per eachLAN-attachable device.

In accordance with a third aspect, there is provided a new CP-terminalremotely attachable to a LAN through an IMS network for controlling oneor more LAN-attachable devices attachable to said LAN.

This CP-terminal includes an IMS device, which has a subscription withan IMS network. This IMS device is arranged for registering andcommunicating with said IMS network, for obtaining from a discoveryserver one or more UUID identifying respective one or moreLAN-attachable devices; and for submitting through the IMS network oneor more IMS commands addressing the one or more UUID towards theResidential Gateway in order to access the LAN for controlling the oneor more LAN-attachable devices.

In particular, this CP-terminal is adapted for obtaining the one or moreUUID from the discovery server, where the discovery server is a PresenceServer of another IMS network, or where the discovery server is a S-CSCFof another IMS network, and where the another IMS network is likely anIMS network wherein an IMS device of the Residential Gateway holds asubscription.

As for the above method, the IMS network wherein the IMS device of theCP-terminal holds a subscription and the IMS network wherein the IMSdevice of the Residential Gateway holds a subscription may be a same IMSnetwork, or different IMS networks.

On the other hand, certain example embodiments may be practised by acomputer program, in accordance with a fourth aspect, the computerprogram being loadable into an internal memory of a computer with inputand output units as well as with a processing unit, and comprisingexecutable code adapted to carry out the above method steps. Inparticular, this executable code may be recorded in a carrier readablein the computer.

BRIEF DESCRIPTION OF THE DRAWINGS

The features, objects and advantages of certain example embodiments willbecome apparent by reading this description in conjunction with theaccompanying drawings, in which:

FIG. 1 basically represents a network scenario showing a number ofLAN-attachable devices accessible by a remote gateway through a home LANwhere the devices are attachable, a discovery server for exposal of thedevices, and a control point terminal for controlling the devicesthrough a public network.

FIG. 2 illustrates a simplified view of the sequence of actions to beperformed to carry out a method of controlling a number ofLAN-attachable devices from a CP registered in an IMS network.

FIGS. 3A and 3B show a simplified view of an exemplary sequence ofactions to be performed in accordance with an embodiment to carry out amethod of controlling a number of LAN-attachable devices from a CPregistered in an IMS network.

FIG. 4 shows an exemplary configuration of a coordination agent withmodules and elements included in a remote gateway for accessingLAN-attachable devices accessible through a home LAN where the devicesare attachable and for receiving control commands from a CP registeredin an IMS network.

DETAILED DESCRIPTION

The following describes currently preferred embodiments of a ResidentialGateway for allowing the access to one or more LAN-attachable devicesthrough a LAN from an IMS network, a CP-terminal remotely attachable tothe LAN through an IMS network for controlling the one or moreLAN-attachable devices, and method of controlling one or moreLAN-attachable devices from a CP-terminal remotely attachable to saidLAN through an IMS network.

For the sake of simplicity, a CP-terminal enabled to register in an IMSnetwork may also be further referred to as a SIP-CP.

FIG. 2 illustrates an embodiment of the method of controlling one ormore LAN-attachable devices from a CP-terminal remotely attachable tosaid LAN through an IMS network.

In this exemplary method, the Remote Gateway 3 initiates during a stepS-010 the discovery of LAN-attachable devices 1 a-1 m through the LAN 4.In particular, this discovery is intended to obtain at the RemoteGateway 3 a list of identifiers of the LAN-attachable devices 1 a-1 m.

More specifically and where the LAN-attachable devices 1 a-1 m areaccessible with different domain-specific protocols, the discovery ofLAN-attachable devices 1 a-1 m may require one or more domain-specificdevices 31 a-31 n of the Residential Gateway 3 to carry out thediscovery of the LAN-attachable devices 1 a-1 m in accordance withcorresponding one or more domain-specific protocols. In this case, saidone or more domain-specific devices 31 a-31 n of the Residential Gatewaymay be adapted for receiving the identifiers of the LAN-attachabledevices.

Once the Remote Gateway 3 has obtained the list of identifiers of theLAN-attachable devices 1 a-1 m, for each identifier of a LAN-attachabledevice, hereinafter “LAN-ADI”, the Remote Gateway generates during astep S-015 a universal unique identifier “UUID” and associates during astep S-020 said UUID with its corresponding LAN-ADI.

At this stage, and if not previously carried out, an IMS device 33 ofthe Remote Gateway 3, as illustrated in FIG. 1 and hereinafter referredto as the first IMS device, registers during a step S-025 with a firstIMS network 51 where the first IMS device holds a subscription.

In particular and as a result of this registration, during a step S-035,the first IMS device is assigned a Serving Call Session Control Server“S-CSCF” 61 of the first IMS network 51, hereinafter a first S-CSCF,namely ‘S-CSCF-1’.

Once the Remote Gateway 3 has generated at least one UUID and hasassociated said UUID with its corresponding LAN-ADI, and once the firstIMS device has registered with the first IMS network, the Remote Gateway3 submits during a step S-045 said at least one UUID towards a discoveryserver 6. In particular, the at least one UUID may be accompanied by arespective SIP address for addressing the corresponding LAN-attachabledevice through said first and second IMS networks. Also in particular,the submission of the least one UUID towards the discovery server 6 maybe carried out as a registration of the least one UUID towards the firstS-CSCF 61.

In this particular case, the discovery server 6 may formerly beinterpreted as said first S-CSCF 61 of the first IMS network 51.Complementary, the Remote Gateway 3 may also submit the UUID registeredin the first S-CSCF 61 towards a Presence Server 62 of the first IMSnetwork 51. In this case, the discovery server 6 may latterly beinterpreted as said Presence Server 62 and the method may furtherinclude, in accordance with an embodiment, a step of publishing the atleast one UUID from said Presence Sever.

Alternatively and in accordance with another embodiment, the discoveryserver 6, where the Remote Gateway 3 submits during the step S-045 theat least one UUID, is the Presence Server 62 of the first IMS network51; and the method may also further include a step of publishing the atleast one UUID from said Presence Sever 62.

A CP-terminal 2 remotely attachable to said LAN through an IMS network,namely a SIP-CP, wanting to initiate any control activity over theLAN-attachable devices 1 a-1 m, needs register with the IMS network. Tothis end, an IMS device 23 of the SIP-CP 2, as illustrated in FIG. 1 andhereinafter referred to as the second IMS device, registers during astep S-030 with a second IMS network 52 where the second IMS deviceholds a subscription. As a result of this registration, during a stepS-040, the second IMS device is assigned a Serving Call Session ControlServer “S-CSCF” of the second IMS network 52, hereinafter a secondS-CSCF, namely ‘S-CSCF-2’.

Once the second IMS device 23 of the SIP-CP 2 has registered with thesecond IMS network 52, said second IMS device 23 can obtain during astep S-050 from the discovery server 6 the at least one UUID submittedthereto from the Remote Gateway 3.

Then, the second IMS device 23 submits during a step S-055, through thefirst and second IMS networks 51-52 one or more IMS commands addressingthe at least one UUID towards the Residential Gateway 3.

The Residential Gateway 3 receiving such one or more IMS commandssubmits during a step S-060 through the LAN 4 corresponding commandsaddressing each corresponding LAN-ADI to each LAN-attachable device 1a-1 m.

In particular, and where the LAN-attachable devices 1 a-1 m areaccessible with different domain-specific protocols, the submission ofcorresponding commands from the Residential Gateway includes a mappingfrom the one or more IMS commands into corresponding domain-specificprotocol commands understandable by the LAN-attachable devices.

Generally speaking, the first IMS network 51, where the IMS device 33 ofthe Remote Gateway 3 holds a subscription, and the second IMS network52, where the IMS device 23 of the SIP-CP 2 holds a subscription, may bedifferent IMS networks owned by different network operators. Inparticular, both first and second IMS networks may be the same IMSnetwork owned by a same network operator.

In order to carry out this method there is provided, as FIG. 1illustrates, a Residential Gateway 3 for accessing the LAN 4, whereinone or more LAN-attachable devices 1 a-1 m are exemplary attached, froman IMS network 51-52; and a CP-terminal 2, remotely attachable to theLAN 4 through the IMS network 51-52 for controlling the one or moreLAN-attachable devices 1 a-1 m. As already commented above and for thesake of simplicity, a CP-terminal enabled to register in an IMS networkmay also be further referred to as a SIP-CP.

FIG. 1 illustrates a basic embodiment of the Residential Gateway 3. ThisResidential Gateway comprises: an IMS device 33 having a subscriptionwith the IMS network 51, which is arranged for registering andcommunicating with said IMS network; one or more domain-specific devices31 a-31 n for discovering the list of identifiers of LAN-attachabledevices through the LAN; and a coordination agent 32 arranged forgenerating a UUID per each LAN-ADI and for associating said UUID withits corresponding LAN-ADI. In particular, the one or moredomain-specific devices may operate in accordance with corresponding oneor more domain-specific protocols respectively handled by theLAN-attachable devices.

Apart from that, in this Remote Gateway, the coordination agent 32 maybe arranged for cooperating with the IMS device 33 for sending the atleast one UUID towards a discovery server 6, 61, or 62; the IMS device33 may be arranged for cooperating with the coordination agent 32 forreceiving from the IMS network 51 the one or more IMS commandsaddressing the one or more UUID; and the coordination agent 32 may bearranged for cooperating with the one or more domain-specific devices 31a-31 n for submitting through the LAN 4 corresponding commandsaddressing each corresponding LAN-ADI to each LAN-attachable device.

Advantageously, where more than one domain-specific protocol exist, theResidential Gateway 3 may further comprise one or more domain-specificprotocol modules 321 a-321 n, as illustrated in FIG. 4, for handling theone or more domain-specific devices 31 a-31 n to carry out the discoveryprocedure of the LAN-attachable devices, to receive the identifiers ofLAN-attachable devices, and to submit the corresponding commands foreach LAN-attachable device. In this respect, FIG. 4 illustrates anembodiment where the coordination agent 32 includes the one or moredomain-specific protocol modules 321 a-321 n. In other embodiments notillustrated in any drawing the one or more domain-specific protocolmodules 321 a-321 n may be provided as an individual element of theResidential Gateway 3, or as an integral part of, or combined with, thedomain-specific devices 31 a-31 n.

In a similar manner as the domain-specific protocol modules 321 a-321 nare provided in the Residential Gateway 3 for handling the one or moredomain-specific devices 31 a-31 n, the Residential Gateway 3 may furthercomprise an IMS protocol module 322 for handling the IMS device 33 toregister in the IMS network 51, to send the at least one UUID towardsthe discovery server 6, 61, or 62 and to receive from the IMS networkthe one or more IMS commands addressing the one or more UUID. In thisrespect, FIG. 4 illustrates an embodiment where the coordination agent32 includes the IMS protocol module 322. In other embodiments notillustrated in any drawing the IMS protocol module 322 may be providedas an individual element of the Residential Gateway 3, or as an integralpart of, or combined with, the IMS device 33.

In an embodiment, where the IMS protocol module 322 and the one or moredomain-specific protocol modules 321 a-321 n are included in thecoordination agent 32 illustrated in FIG. 4, such coordination agent ofthe Residential Gateway 3 may further include a controller 320 forinterfacing the IMS protocol module 322 and the one or moredomain-specific protocol modules 321 a-321 n, and for mapping the one ormore IMS commands addressing the one or more UUID into the correspondingcommands addressing each corresponding LAN-ADI. Aligned with aboveembodiments, which are not illustrated in any drawing, the IMS protocolmodule 322, the domain-specific protocol modules 321 a-321 n and thecontroller 320 may be provided as individual elements of the ResidentialGateway 3.

Taking into account that the Residential Gateway 3 associates, for eachLAN-attachable device, the UUID with its corresponding LAN-ADI, theResidential Gateway may further include a storage 323 arranged forstoring each UUID associated with its corresponding LAN-ADI per eachLAN-attachable device. Moreover, where more than one domain-specificprotocol exists, the storage 323 of the Residential Gateway 3 may bearranged for also storing an indication of the applicabledomain-specific protocol per each LAN-attachable device.

FIG. 1 also illustrates a basic embodiment of the SIP-CP 2. This SIP-CPcomprises: an IMS device 23, which has a subscription with an IMSnetwork 52 and is arranged for registering and communicating with saidIMS network. This IMS device 23 is arranged for obtaining from adiscovery server 6, 61 or 62 the one or more UUID identifying therespective one or more LAN-attachable devices 1 a-1 m; and is alsoarranged for submitting through the IMS network 52 the one or more IMScommands addressing the one or more UUID towards the Residential Gateway3 for accessing the LAN 4 for controlling the one or more LAN-attachabledevices 1 a-1 m.

In particular, the discovery server addressable from the IMS device 23of the SIP-CP 2 may be the Presence Server 62 or the S-CSCF 61 of theIMS network 51, where the IMS device 33 of the Residential Gateway 3holds its subscription.

In the following a further particular embodiment is discussed withreference to FIG. 3A-3B.

Under this further particular embodiment, FIG. 3A illustrates a firstsequence of actions involving the discovery of LAN-attachable devices bythe Remote Gateway and preparations for publication at a PresenceServer, whereas FIG. 3B illustrates the device control by theCP-terminal.

As illustrated in FIG. 3A, the Remote Gateway 3 initiates the discoveryof LAN-attachable devices 1 a-1 m through the LAN 4 during a step S-010,as for the previous embodiment illustrated in FIG. 2. The discovery isintended to obtain at the Remote Gateway 3 the list of identifiers ofthe LAN-attachable devices 1 a-1 m.

As for the embodiment illustrated in FIG. 2, also for this embodimentillustrated in FIG. 3A, and where the LAN-attachable devices 1 a-1 m areaccessible with different domain-specific protocols, the discovery ofLAN-attachable devices may require one or more domain-specific devices31 a-31 n of the Residential Gateway 3 to carry out the discovery, andto receive the identifiers, of the LAN-attachable devices in accordancewith more than one domain-specific protocol.

The Remote Gateway 3 may thus command a set of built-in domain-specificprotocol modules (realized as physical electronic subsystems using e.g.discrete digital chips), each module supporting a given communicationsprotocol (e.g. SIP, DLNA, UPnP etc.), to discover other devices attachedto the home LAN supporting that same communications protocol; allocatinga UUID to each discovered LAN-attachable device and storing in aninternal memory 323 an association between the allocated UUID and theprotocol-specific device identifier (e.g. SIP AoR in case of aSIP-supporting device, or device URN in case of a UPnP-supportingdevice) and device characteristics (e.g. supported media codecs, networkaddresses, supported capabilities, etc).

Once the Remote Gateway 3 has obtained the list of identifiers of theLAN-attachable devices “LAN-ADI”, for each LAN-ADI, the Remote Gatewaygenerates during a step S-015 a universal unique identifier “UUID” andassociates during a step S-020 said UUID with its corresponding LAN-ADI.

At this stage, and if not previously carried out, the first IMS device33 of the Remote Gateway 3 illustrated in FIG. 1 registers during a stepS-075 with the first IMS network 51 where the first IMS device holds asubscription. As a result of this registration, an OK response to theregistration and received during a step S-080, the first IMS device isassigned a first S-CSCF 61, namely ‘S-CSCF-1’, of the first IMS network51.

The Remote Gateway 3 may contain an IMS endpoint that includes an ISIMbound to an IMS service subscription and one or more SIP Address ofRecord (hereinafter SIP-AoR) associated to said subscription.

Complementary to the registration of the IMS device 33, and not shown inany drawing, for each LAN-attachable device discovered above, the RemoteGateway issues a registration request towards the S-CSCF 61 in the firstIMS network 51, including in each request a ‘Contact’ header containingthe UUID discovered during the discovery phase.

On reception of each OK response to each registration request, theRemote Gateway extracts the value of an ‘Expires’ header in thatresponse and starts a periodic timer to be set to time-out after thetime that corresponds to that value has elapsed; so that on eachtime-out the Remote Gateway may command the correspondingdomain-specific protocol module to restart the discovery of aLAN-attachable device. In this way, the S-CSCF 61 in the IMS networkalways has an accurate view of the devices currently active in the homeLAN.

In this embodiment, from time to time, the S-CSCF 61 of the first IMSnetwork 51 notifies during steps S-090 the Remote Gateway of any SIP AoRthat has been registered using the same subscription and the ‘Contact’addresses bound to said AoR. Where this happens, the Remote Gateway 3extracts the ‘Contact’ addresses and, likely after having successfullyanswered the notification during a step S-095, the Remote Gateway 3 maypublish it during a step S-100 in a Presence Server 62 of the first IMSnetwork, bound to the respective SIP AoR. In this way, theLAN-attachable devices attached to the home LAN 4 become visible fromany SIP-CP 2 with access to the IMS network of the Presence Server.Along with the ‘Contact’ address, the Remote Gateway may publish knowncharacteristics of each LAN-attachable device in the form of adescriptive document expressed in a machine-understandable language.This allows other entities to know more details about that device (e.g.if a LAN-attachable device is an MP3 player, it would be useless tostream a video to that device; thus, the aforementioned documentexpresses that the device it is describing only supports audio).

As already commented above, a CP-terminal 2 remotely attachable to thehome LAN through an IMS network, namely a SIP-CP, wanting to initiateany control activity over the LAN-attachable devices 1 a-1 m, needsregister with the IMS network. To this end, and not illustrated in FIG.3A-3 b but similar as for the embodiment illustrated in FIG. 2, an IMSdevice 23 of the SIP-CP 2, namely the second IMS device, registers witha second IMS network 52 where the second IMS device holds asubscription. As a result of this registration the second IMS device isassigned an S-CSCF of the second IMS network 52, namely ‘S-CSCF-2’ notillustrated in any drawing.

Once the second IMS device 23 of the SIP-CP 2 has registered with thesecond IMS network 52, said second IMS device 23 may query during a stepS-110 the presence server 62, as illustrated in FIG. 3B, about theavailable LAN-attachable devices. This query may be carried out in theform of a subscription towards the presence server during the step S-110and a successful result during a step S-115. The presence server 62 mayreturn a notification during a step S-120 with a SIP URI for each UUIDthat can be addressed. Such notification may be successfully answered bythe SIP-CP 2 during a step S-125.

Then, the second IMS device 23 submits during a step S-130, through thefirst and second IMS networks 51-52, one or more IMS commands with a SIPInvite message addressing the at least one UUID towards the ResidentialGateway 3.

When the Remote Gateway receives the SIP Invite addressing any SIP AoR,the Remote Gateway knows they are registered using the samesubscription, it checks for the presence of a parameter including a UUIDin the contents of the ‘P-Called-Party’ header and, if that is the case,it checks the UUID against the internal memory 323; if there is a match,the Remote Gateway extracts the body of the SIP Invite, which mightinclude one or more commands that are to be passed to the LAN-attachabledevice associated with the UUID, and passes these IMS commands to thecorresponding domain-specific protocol module. The protocol module mapsduring a step S-135 these IMS commands to semantically equivalentcommands expressed in the language of the protocol that thedomain-specific protocol module supports and sends during a step S-140the mapped commands to the concerned LAN-attachable device. In thisrespect, the SIP Invite might carry no command at all; nevertheless, theRemote Gateway might be able to figure out the issuing SIP device in thepublic IMS network from such invitation, and might instruct thecorresponding domain-specific protocol module to generate thesemantically equivalent commands in the language of the protocolsupported by that module. For example, a SIP Invite request carrying nocommand in its body might be interpreted by the Remote Gateway as acommand to start playing certain media file at the addressedLAN-attachable device.

Any mapped command passed to the LAN-attachable devices may trigger acorresponding response at that device that arrives to the correspondingdomain-specific protocol module in the Remote Gateway. The RemoteGateway might map during a step S-150 those responses to semanticallyequivalent SIP responses and might submit the mapped SIP responsestowards the CP-terminal 2 during a step S-155. Said responses mightinclude respective response bodies containing documents expressed in anabstract, domain-independent language in order to match the degree ofexpressiveness of the SIP response to that of the domain-specificprotocol response, that is, the domain-specific protocol response mightcontain a human-readable text indicating why the respective commandfailed, and that text might be packed in the body of a 3 xx SIP responsethat would be sent to the SIP device in the public IMS network.

In the following further particular embodiments are discussed with aneye to illustrate the reader on several advantageous implementationswith specific details.

The coordination agent 32 of the Remote Gateway 3 is connected with theIMS device 33 on one side and with as many domain-specific devices 31a-31 n as different protocols are used inside the home LAN 4 on theother side.

This coordination agent 32 of the Remote Gateway 3 may include, as shownin FIG. 4, a re-writable random access memory 323 that in turn includesa dual-column table with associative properties, so that when a stringof octets is applied to one side of this memory it finds the table rowcontaining said string in that side and returns the string of octets inthe same row on the opposite side.

In order to carry out the discovery of LAN-attachable devices 1 a-1 m,the coordination agent 32 may activate in sequence each of itsdomain-specific protocol modules. On activation, a domain-specificprotocol module: requests the domain-specific device to perform a homeLAN device discovery according to the procedures defined for thedomain-specific protocol; gathers from the domain-specific device theresult of the device discovery, in the form of a list of identifiers forthe discovered LAN-attachable devices 1 a-1 m, namely a list of LAN-ADI,each identifier having an associated description in the form ofattribute-value pairs or any other format defined by the domain-specificprotocol. For each gathered device identifier, the domain-specificprotocol module: generates a UUID, which may be made of, or be part of,or be the LAN-ADI; stores in a free row in the associative table 323 thecouple of LAN-ADI and UUID; and requests the IMS device 33 to registerin S-CSCF 61 of the first IMS network 51, including as parameter of the‘Contact’ header in the REGISTER request a URN encapsulating thejust-generated UUID. Optionally, once the registration is complete, thedomain-specific protocol module may compose a presence documentaccording to the well known PIDF format, from the description associatedto the LAN-ADI once processed, and may request the IMS device 33 topublish the presence status of the SIP URI in the ‘Contact’ headerreceived in the 200 response from the S-CSCF 61 associated to thecomposed PIDF-compliant presence document.

Depending on the different domain-specific protocols supported by thedifferent LAN-attachable devices 1 a-1 m, different discovery proceduresmay turn up. For instance, if the domain-specific protocol is aso-called UPnP, the UPnP-specific device multicasts on the home LAN 4 anM-SEARCH HTTP request addressing the UPnP SSDD multicast address andport.

In order to keep fresh the list of discovered LAN-attachable devices andtheir identifiers, namely LAN-ADI's, the coordination agent 32 mayre-activate any or all of its domain-specific protocol modules. Oneoptimum way of performing the re-activation is doing it before expiry ofthe time established by the value of the “Expires” header set by theS-CSCF in the 200 response to the REGISTER request elapses, so that theregistrations in the S-CSCF are kept accurate.

On the other hand, thanks to the subscription to registration statusthat the IMS device 23 in the remote SIP-CP 2 maintains, a controlapplication in the remote SIP-CP, not illustrated in any drawing,receives notifications of each registration performed by thecoordination agent 32. This allows the control application to keep anup-to-date view of the LAN-attachable devices in the home LAN 4.

Regarding the CP-terminal 2, generally referred to as SIP-CP throughoutthe present specification, further embodiments and some advantageousimplementation details are discussed in the following.

For instance, where the control application in the remote SIP-CP 2determines the issue of a command addressing a specific LAN-attachabledevice, the control application firstly obtains the SIP URI of saidLAN-attachable device. Said SIP URI may be obtained in one of two ways:from the reg-event XML documents received by the IMS device 23 of theSIP-CP 2 in notifications about registration status issued by the S-CSCF61; or, if the coordination agent has published presence informationabout the discovered LAN-attachable devices, the SIP-CP may query thepresence server 62 for the available LAN-attachable devices. Thepresence server 62 may return the list of SIP URIs that can beaddressed.

From the above two approaches the latter one is preferable, since fromthe presence information stored about each published SIP URI a user maybe able to know the type and characteristics of the device to which saidSIP URI corresponds. However, if a user knows certainly the type andcharacteristics of the device to which a SIP URI corresponds, the firstapproach is equally suitable.

Once the SIP URI that corresponds to the desired LAN-attachable deviceis obtained, the SIP-CP prepares a document containing the command orcommands to be issued to said LAN-attachable device, includes them inthe body of a suitable SIP request (e.g. an INVITE request fordownloading/uploading digital content or a MESSAGE request for a simplecommand or set of commands) and requests the IMS device in the SIP-CP tosend said request to the SIP URI of the LAN-attachable device.

The IMS device 33 connected to the coordination agent 32, on receptionof the SIP request, passes it to the coordination agent 32. Thecoordination agent 32 injects the UUID in the so-called ‘gr’ parameterof the SIP URI in the ‘Called-Party-ID’ header of the received requestinto the associative table and obtains the LAN-ADI of thedomain-specific protocol used to command that LAN-attachable device.Then, it extracts the body of the SIP request, converts it into anequivalent command in the domain-specific protocol, and requests therelevant domain-specific device 31 a-31 n to send the command to theLAN-ADI obtained above. The commanded LAN-attachable device may return aresponse to the control command that may be received by thedomain-specific device 31 a-31 n, which passes it to the coordinationagent 32. In that case, the coordination agent 32 puts the response inthe body of a SIP response to the request that carried the command; setsthe status code of the response to a sensible value (e.g. 200-class ifthe command response indicates the operation was executed successfullyor 500-class otherwise); and requests the IMS device 33 to return theSIP response to the issuer of the corresponding SIP request.

In addition to overcoming the drawbacks of certain example embodiments,the above teaching may thus offer the advantage of simplifying thecomplexity of the SIP-CP by removing the needs for supportingarrangements of a Virtual Private Network and multiple controlprotocols. Moreover, with the optional presence of extensions, it allowsusers to share LAN-attachable devices with other users and to grant ordeny access to said devices by means of presence information access withwhite lists and black lists. Furthermore, the operator of the IMSnetwork can provide value-added services involving specificLAN-attachable devices in the home LAN.

Certain example embodiments may also be practised by a computer program,loadable into an internal memory of a computer with input and outputunits as well as with a processing unit. This computer program comprisesto this end executable code adapted to carry out the above method stepswhen running in the computer. In particular, the executable code may berecorded in a carrier readable means in a computer.

The embodiments described above in connection with various embodimentsthat are intended to be illustrative and non-restrictive. It is expectedthat those of ordinary skill in this art may modify these embodiments.The scope of the invention is defined by the claims in conjunction withthe description and drawings, and all modifications that fall within thescope of the claims are intended to be included therein.

The invention claimed is:
 1. A method of controlling one or more devicesattachable to a local area network (LAN) from a control point (CP)terminal that is remotely attachable to the LAN through an IP MultimediaSubsystem (IMS) network, the method comprising: registering a first IMSdevice of a residential gateway with a first IMS network that holds asubscription for said first IMS device; discovering by the residentialgateway a list of identifiers of LAN-attachable devices of the LAN; foreach identifier (LAN-ADI) of a LAN-attachable device the residentialgateway generating a universal unique identifier (UUID) and associatingsaid UUID with the corresponding LAN-ADI; sending at least one UUID fromthe residential gateway to a discovery server; registering a second IMSdevice of a CP-terminal with a second IMS network that has asubscription for said second IMS device; obtaining, with the second IMSdevice, the at least one UUID from the discovery server; submitting,with the second IMS device, one or more IMS commands via said first andsecond IMS networks addressing the at least one UUID to the residentialgateway; and submitting, via the residential gateway and through theLAN, corresponding commands addressing corresponding LAN-ADI to eachLAN-attachable device of the LAN-attachable devices.
 2. The method ofclaim 1, further comprising requesting to one or more domain-specificdevices of the residential gateway a discovery of the at least oneLAN-attachable device in accordance with corresponding one or moredomain-specific protocols; and receiving the list of identifiers ofLAN-attachable devices from the one or more domain-specific devices ofthe residential gateway.
 3. The method of claim 1, wherein each UUID isaccompanied by a respective session initiation protocol (SIP) addressfor addressing a corresponding LAN-attachable device of theLAN-attachable devices through said first and second IMS networks. 4.The method of claim 1, wherein submitting the corresponding commandsincludes mapping the one or more IMS commands into correspondingdomain-specific protocol commands understandable by the LAN-attachabledevices.
 5. The method of claim 1, wherein the discovery server is apresence server of the first IMS network and the method furthercomprises transmitting the at least one UUID from said presence server.6. The method of claim 1, wherein: registering the first IMS deviceincludes assigning a serving call session control server (S-CSCF) of thefirst IMS network to the first IMS device as a result of theregistration of the first IMS device, and sending the at least one UUIDto the discovery server includes registering the at least one UUID fromthe first IMS device to said S-CSCF.
 7. The method of claim 6, whereinthe discovery server is the S-CSCF of the first IMS network.
 8. Themethod of claim 6, further comprising: submitting the at least one UUIDregistered in the S-CSCF to a presence server of the first IMS network;and transmitting the at least one UUID from said presence server,wherein the discovery server is said presence server.
 9. The method ofclaim 1, wherein the first and second IMS networks are a same IMSnetwork.
 10. A residential gateway for accessing to a local area network(LAN) that is configured to have one or more LAN-attachable devicescommunicatively attachable thereto, the residential gateway accessiblefrom an IP multimedia subsystem (IMS) network that has a control point(CP) terminal communicatively connected thereto, the residential gatewaycomprising: an IMS device having a subscription with an IMS network, theIMS device configured to register and communicate with the IMS network;a domain-specific device configured to discover a list of identifiers ofLAN-attachable devices through the LAN; and a coordination agent thatis, when implemented on at least one processing unit, configured to:generate a universal unique identifier (UUID) for each identifier(LAN-ADI) of the list of identifiers of LAN-attachable devices;associate said UUID with the corresponding LAN-ADI; and cooperate withthe IMS device to send at least one UUID to a discovery server; whereinthe IMS device is further configured to cooperate with the coordinationagent to receive, from the IMS network, one or more IMS commandsaddressing the at least one UUID, wherein the coordination agent isfurther configured to cooperate with the domain-specific device tosubmit, via the LAN, corresponding commands addressing eachcorresponding LAN-ADI to each LAN-attachable device.
 11. The residentialgateway of claim 10, wherein the domain specific device operates inaccordance with a corresponding domain-specific protocol handled by theLAN-attachable devices.
 12. The residential gateway of claim 10, furthercomprising: a domain-specific protocol module that is, when implementedon the at least one processing unit, configured to: handle thedomain-specific device to carry out discovery of the LAN-attachabledevices; receive the list of identifiers of LAN-attachable devices; andsubmit the corresponding commands for each LAN-attachable device. 13.The residential gateway of claim 10, further comprising an IMS protocolmodule that is, when implemented on the at least one processing unit,configured to: handle the IMS device to register in the IMS network;send the at least one UUID to the discovery server; and receive from theIMS network the one or more IMS commands addressing the one or moreUUID.
 14. The residential gateway of claim 12, further comprising acontroller that is, when implemented on the at least one processingunit, configured to: interface the IMS protocol module and thedomain-specific protocol module; map the one or more IMS commandsaddressing the one or more UUID into the corresponding commandsaddressing each corresponding LAN-ADI.
 15. The residential gateway ofclaim 10, further comprising a storage medium configured to, inconjunction with the processing unit, store each UUID associated withthe corresponding LAN-ADI per each LAN-attachable device.
 16. Theresidential gateway of claim 15, wherein the storage medium is furtherconfigured to, in conjunction with the processing unit, store anindication of the applicable domain-specific protocol per eachLAN-attachable device.
 17. A control point (CP) terminal that isremotely attachable to a local area network (LAN) through an IPmultimedia subsystem (IMS) network for controlling one or moreLAN-attachable devices, the CP-terminal comprising: an IMS device havinga subscription with an IMS network and that is, when implemented on atleast one processing unit, configured to: register and communicate withsaid IMS network; obtain, from a discovery server, one or more universalunique identifier (UUID) that respectively identify one or more of theLAN-attachable devices; and submit, via the IMS network, one or more IMScommands that address the one or more UUID to a residential gateway foraccessing to the LAN for controlling the one or more LAN-attachabledevices.
 18. The CP-terminal of claim 17, wherein the discovery serveris a presence server of another IMS network where a second IMS device ofthe residential gateway has a subscription.
 19. The CP-terminal of claim17, wherein the discovery server is a serving call session controlserver (S-CSCF) of another IMS network where a second IMS device of theresidential gateway holds a subscription.
 20. The CP-terminal of claim18, wherein the IMS network and the another IMS network, where a secondIMS device of the residential gateway holds a subscription, are a sameIMS network.